Allow grid to use style variation blockGap values for columns calcula… by tellthemachines · Pull Request #10906 · WordPress/wordpress-develop

tellthemachines · 2026-02-12T00:28:57Z

…tion

Trac ticket: https://core.trac.wordpress.org/ticket/64624

Syncs changes from WordPress/gutenberg#75360.

Use of AI Tools

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

github-actions · 2026-02-12T00:29:07Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props isabel_brison, mukesh27, westonruter, andrewserong.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

github-actions · 2026-02-12T00:42:14Z

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

mukeshpanchal27 · 2026-02-12T04:40:48Z

src/wp-includes/block-supports/layout.php

+ * @param array  $registered_styles Currently registered block styles.
+ *
+ * @return string|null The name of the first registered variation, or null if none found.


Suggested change

* @param array $registered_styles Currently registered block styles.

*

* @return string|null The name of the first registered variation, or null if none found.

* @param array $registered_styles Currently registered block styles.

* @return string|null The name of the first registered variation, or null if none found.

Per document standard https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#1-functions-class-methods

mukeshpanchal27 · 2026-02-12T04:44:27Z

tests/phpunit/tests/block-supports/layout.php

+			)
+		);
+
+		// WP_Theme_JSON_Resolver::clean_cached_data();


Do we actually need this code here, or was it added by mistake?

It was added in tear_down method so better to remove it from test.

Ah, well spotted! I was experimenting and forgot to remove it 😅

tests/phpunit/tests/block-supports/layout.php

westonruter · 2026-02-12T07:49:59Z

tests/phpunit/tests/block-supports/layout.php

+					'type'               => 'grid',
+					'columnCount'        => 3,
+					'minimumColumnWidth' => '12rem',
+


Suggested change

westonruter · 2026-02-12T07:50:24Z

tests/phpunit/tests/block-supports/layout.php

+		// Clean up.
+		remove_theme_support( 'appearance-tools' );


This should go in tear_down, yeah?

I'm not sure. I'm seeing adding/removing of theme supports per test in most places, and the support is added inside the test so I thought I'd remove it there too. Though for this one I guess it won't make any difference practically, because it's removed at the end of the test.

Actually thinking better about it, we shouldn't need appearance-tools support here at all!

westonruter · 2026-02-12T07:55:01Z

src/wp-includes/block-supports/layout.php

+ * @param string $class_name        CSS class string for a block.
+ * @param array  $registered_styles Currently registered block styles.


Can the array param be more specific? For example (if this is accurate):

Suggested change

* @param string $class_name CSS class string for a block.

* @param array $registered_styles Currently registered block styles.

* @param string $class_name CSS class string for a block.

* @param array<string, array<string, mixed>> $registered_styles Currently registered block styles.

westonruter · 2026-02-12T07:55:49Z

src/wp-includes/block-supports/layout.php

+	$prefix = 'is-style-';
+	$len    = strlen( $prefix );
+
+	foreach ( explode( ' ', $class_name ) as $class ) {
+		if ( str_starts_with( $class, $prefix ) ) {
+			$variation = substr( $class, $len );


Best to not abbreviate the variable names:

Suggested change

$prefix = 'is-style-';

$len = strlen( $prefix );

foreach ( explode( ' ', $class_name ) as $class ) {

if ( str_starts_with( $class, $prefix ) ) {

$variation = substr( $class, $len );

$prefix = 'is-style-';

$length = strlen( $prefix );

foreach ( explode( ' ', $class_name ) as $class ) {

if ( str_starts_with( $class, $prefix ) ) {

$variation = substr( $class, $length );

westonruter · 2026-02-12T07:56:07Z

src/wp-includes/block-supports/layout.php

+ *
+ * @return string|null The name of the first registered variation, or null if none found.
+ */
+function wp_get_variation_name_from_class( $class_name, $registered_styles = array() ) {


Suggested change

function wp_get_variation_name_from_class( $class_name, $registered_styles = array() ) {

function wp_get_variation_name_from_class( string $class_name, $registered_styles = array() ): ?string {

andrewserong

Just a couple of thoughts re: the new utility function (sorry I didn't catch this in the Gutenberg PR!):

Would wp_get_variation_name_from_class be better placed in block-style-variations.php?
There's an existing function wp_get_block_style_variation_name_from_class that accepts only a single param (class name). Would it be worth it to combine the logic into that existing function, with the optional second param? I.e. if the second param is empty, simply check against the classname, but if it's given a list of registered variations, then iterate over the list to find from the actual list of variations?
Alternately, still have this be a separate function, but give it consistent naming with the existing utility function, and co-locate it beside that function

Hope that all made sense, it's a useful function, though, and sounds like a good addition overall to me 👍

tellthemachines · 2026-02-13T05:28:56Z

There's an existing function wp_get_block_style_variation_name_from_class that accepts only a single param (class name). Would it be worth it to combine the logic into that existing functions, with the optional second param?

Yeah that's a good question. Also, it looks like wp_render_block_style_variation_support_styles which uses that helper function is rendering styles without checking whether they're registered or not. Should layout do that too?

Otherwise, I think we could consolidate the two functions into one.

andrewserong · 2026-02-13T05:47:04Z

Also, it looks like wp_render_block_style_variation_support_styles which uses that helper function is rendering styles without checking whether they're registered or not. Should layout do that too?

Oh, good point. Yeah, just as in wp_render_block_style_variation_support_styles, it looks like you're only using the $variation_name to access a key in the global styles data, so if there are any unregistered classnames that are a match, it'd return null anyway. So yeah, given that function works that way, it sounds like you could use the same approach here as the style engine will sanitize output, anyway.

Still, I don't mind the additional check (and the idea of adding it into the existing function via a second param) as it does give an additional polish of making sure that we're only looking up values that can exist.

Up to you, I think, if you prefer the clarity or "correctness" of the additional check, or the simplicity of re-using the existing function. (Personally I think it's a valid choice either way).

tellthemachines · 2026-02-16T03:10:36Z

Hmm I might try reusing the existing function for consistency.

…tion

tellthemachines · 2026-02-16T04:22:15Z

Hmm I might try reusing the existing function for consistency.

Actually, looking closer at wp_get_block_style_variation_name_from_class it might be a bit messy to reuse it because from $block['attrs']['className'] it returns an array of matching class names that include both the variation name and another name derived from the actual classname the styles are attached to, such as name--3. Might be best to keep the two separate functions after all. I'd leave the new one one in layout for now because it's the only place we're using it, and we can change that if we ever need to use it somewhere else.

I'll add a test for the new function too.

andrewserong · 2026-02-16T04:35:20Z

it might be a bit messy to reuse it because

Ah, fair enough! To make sure the name is distinct from the existing function would it be worth renaming the new function to something like: wp_get_block_style_variation_name_from_registered_style? It'll be included in the global namespace, so it could help folks looking up functions if the names a little more different from each other.

I'd leave the new one one in layout for now because it's the only place we're using it, and we can change that if we ever need to use it somewhere else.

Up to you, but I'd lean toward co-locating it with the other function, just because they're both global functions, and it sometimes feels a little odd when similar utility functions are in different locations. Though I get that it also makes sense to keep it close to where it's mostly used! If so, you could always put layout somewhere in the function name if you wanted make it clear it's for use in the layout support.

…_class

tellthemachines · 2026-02-16T05:01:46Z

wp_get_block_style_variation_name_from_registered_style

Yeah that sounds good, I'll rename it!

Though I get that it also makes sense to keep it close to where it's mostly used! If so, you could always put layout somewhere in the function name if you wanted make it clear it's for use in the layout support.

It could be used somewhere else, so it's probably best for the name not to imply otherwise. I like to have single use utilities live where they're used for code reading convenience, though that's a personal preference. But I don't think we have any clear cut rules around this sort of thing. If it ever gets used elsewhere in block supports, I'd be inclined to move it to src/wp-includes/block-supports/utils.php instead. But that feels like overkill for something used only in one place.

andrewserong · 2026-02-16T05:06:50Z

All sounds reasonable to me!

src/wp-includes/block-supports/layout.php

Co-authored-by: Weston Ruter <westonruter@gmail.com>

andrewserong

This is testing well for me on the server-side / site-frontend with the custom block style from WordPress/gutenberg#75360, and it sounds like the in-editor behaviour will land when gutenberg is resynced with trunk later in the week.

Looks like @westonruter's feedback's been addressed, so this all LGTM! Thanks for all the back and forth 👍

tellthemachines · 2026-02-16T23:11:34Z

Thanks for the reviews folks!

github-actions · 2026-02-16T23:51:15Z

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 61655
GitHub commit: e1d2179

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

tellthemachines self-assigned this Feb 12, 2026

tellthemachines requested a review from ramonjd February 12, 2026 00:31

tellthemachines mentioned this pull request Feb 12, 2026

Allow grid to use style variation blockGap values for columns calculation WordPress/gutenberg#75360

Merged

github-actions bot mentioned this pull request Feb 12, 2026

PHP backports for WP 7.0 WordPress/gutenberg#74043

Open

mukeshpanchal27 reviewed Feb 12, 2026

View reviewed changes

westonruter reviewed Feb 12, 2026

View reviewed changes

andrewserong reviewed Feb 13, 2026

View reviewed changes

tellthemachines force-pushed the fix/grid-with-style-vars branch from 6d3822f to 54f1554 Compare February 13, 2026 04:42

tellthemachines mentioned this pull request Feb 13, 2026

Grid block iteration for 7.0 WordPress/gutenberg#73773

Closed

8 tasks

tellthemachines added 2 commits February 16, 2026 14:11

Allow grid to use style variation blockGap values for columns calcula…

268833d

…tion

clean up

f24eb61

tellthemachines force-pushed the fix/grid-with-style-vars branch from d568f4f to f24eb61 Compare February 16, 2026 03:12

Improve formatting and types; add test for wp_get_variation_name_from…

596b395

…_class

update function name

501b8c8

westonruter reviewed Feb 16, 2026

View reviewed changes

src/wp-includes/block-supports/layout.php Outdated Show resolved Hide resolved

westonruter reviewed Feb 16, 2026

View reviewed changes

src/wp-includes/block-supports/layout.php Outdated Show resolved Hide resolved

westonruter reviewed Feb 16, 2026

View reviewed changes

src/wp-includes/block-supports/layout.php Outdated Show resolved Hide resolved

tellthemachines and others added 2 commits February 16, 2026 17:09

use ! instead of empty() and remove redundant parentheses

3029a5f

Co-authored-by: Weston Ruter <westonruter@gmail.com>

update test name to match function name

34094bb

andrewserong approved these changes Feb 16, 2026

View reviewed changes

github-actions bot closed this Feb 16, 2026

tellthemachines mentioned this pull request Feb 17, 2026

Update gutenberg to match core after #75360 sync WordPress/gutenberg#75594

Merged

		* @param string $class_name CSS class string for a block.
		* @param array $registered_styles Currently registered block styles.

	function wp_get_variation_name_from_class( $class_name, $registered_styles = array() ) {
	function wp_get_variation_name_from_class( string $class_name, $registered_styles = array() ): ?string {

Conversation

tellthemachines commented Feb 12, 2026

Use of AI Tools

Uh oh!

github-actions bot commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Feb 12, 2026

Test using WordPress Playground

Some things to be aware of

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewserong left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tellthemachines commented Feb 13, 2026

Uh oh!

andrewserong commented Feb 13, 2026

Uh oh!

tellthemachines commented Feb 16, 2026

Uh oh!

tellthemachines commented Feb 16, 2026

Uh oh!

andrewserong commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tellthemachines commented Feb 16, 2026

Uh oh!

andrewserong commented Feb 16, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

andrewserong left a comment

Choose a reason for hiding this comment

Uh oh!

tellthemachines commented Feb 16, 2026

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments

github-actions bot commented Feb 12, 2026 •

edited

Loading

andrewserong left a comment •

edited

Loading

andrewserong commented Feb 16, 2026 •

edited

Loading